Subject: RE: Mel Jones comments on CMINTA

From: "Hildebrand, Jeff" <[email-masked]>
Date: Mon, 09 Aug 93 11:53:00 PDT

Mel,
Thanks for the response.  My rebuttal to your points follows (>).
Thanks,
Jeff
 -------------------------------------------------------------------
Jeff:

Sorry for the delay in response, but I've been out of the office much
of the time since the last CIW.

To give some form to my comments, let me classify the portions of your
proposal into two categories:

  1. Alternative procedure for CPIC to access the directory
     a. a new CMINIT call instead of Set_Partner_ID

  2. New function
     a. Specification of the type of identifier provided by the program
     b. Specification of association/session addressing in the directory
        entry (e.g., inclusion of NSAP)

I'll address each of these portions in turn in the sections below.

 -------------------------------------------------------
1. Alternative procedure for CPIC to access the directory
   a. a new CMINIT call instead of Set_Partner_ID, e.g., CMINITA

R0.  There's a part of me that has to say this is a good idea, since
this idea (actually, something called CMINIT2) was part of the
original directory proposal I came up with back in 1992.  There's
another part of me though, the part that went through the battles
that led to the current AD proposal, that recognizes there are
some problems with creating a second CMINIT call.  Some of these
arguments come down to a "beauty contest" of what seems better to
the person looking at it; some are real technical considerations.
Here's a little bit of the discussion (as best I can remember
from the distance):
>
>It is important to figure out a way to expand a service's capability
>in such a way that it is: 1. backwards compatible and 2. that it is
>recognizable by the user as being related to the existing service.
>The purpose of an API is to aid people, not confuse them.  There
>needs to be a CPIC standard nomenclature for expanded services. I chose
>CMINITA simply because A was the first letter of the alphabet -
>there are probably better methods.  One method that would not be
>good is to radically change a service's name, for example CMINITA
>is much better than CMVVTY - I can deduce CMINITA is related to
>CMINIT in some way, CMVVTY does not do that.
>
R1.  There is a distinction between local and non-local calls, i.e.,
calls that block or don't block.  The current CMINIT is considered to be
strictly local and never hangs.  The proposed call, as you described it
(and as I originally described CMINIT2) would have to go off to the
directory and get the directory information.... which would mean that it
might block.  Making the call block (and it's your first call) means that
all of the stuff the non-blocking call allows you to set for queues,
etc., would have be specified on the call.  And what if the program
doesn't want to handle blocking (or, vice versa, a non-blocking call).
Etc. etc.  It gets very complicated and suddenly makes what was a simple
idea -- make this call, get a conv_ID -- start to seem complicated, and
duplicate function built in elsewhere.

R2.  The alternative path to paragraph R1 is to change the function
slightly -- you still let the program issue the call and specify it's DN
or whatever, you just don't actually access the directory at that point.
Now the problems with the blocking call are removed.  Unfortunately, this
now kludges up the other semantics of the call -- what if the
sym_dest_name was local and therefore the system could indeed resolve it
(as for side info)?  Do we now say that sometimes the destination_info
gets resolved and sometimes it doesn't happen until Allocate?
What about the difference between this call and the call that seems to
be the same name -- one actually gets data you can issue sets against,
but the other doesn't?  It quickly starts to get "messy" and no longer
"clean."
>R1 & R2 together
>
>1. The blocking problem is kind of a red herring.  The same
>   'amount' of work will have to be done some where before
>   the transaction can progress.  This slow down will either
>   occur at CMINIT time or ALLOC time - take your pick. And,
>   with a properly designed directory mechanism it shouldn't
>   be a problem.
>
>2. There seems to be an assumption that CPIC over LU 6.2 can
>   resolve names faster than CPIC over OSI.
>   The reason LU 6.2 appears fast is because the LU
>   addresses are gen'd into VTAM. The LU name retrieved
>   from the SET-Partner-LU or side info only really has to
>   provide and index into an in core VTAM table.
>   This approach is a winner because it cannot block.
>
>   The OSI X.500 approach can be as fast as VTAM and be
>   totally nonblocking. The image many people have of X.500 is
>   a centralized database stuck somewhere on the network, along
>   with all the delay that entails.  An X.500 installation can
>   look and behave that way, but it need not.
>
>   An X.500 DSA (the database and access mechanism that contains
>   X.500 data) can be automatically replicated (X.500 term:
>   shadowing) as a whole or in part.  Shadowing is an automatic
>   function.  The local copy of the remote DSA will be updated
>   automatically as the remote DSA is modified.  Blocking due to
>   network delays are totally eliminated.  The only possible
>   delay is the physical access of the database, but then VSAM
>   has the same problem.
>
>   If a local copy of the DSA is not fast enough then the DUA
>   (Directory User Agent - the thing the program contacts for
>   access to the DSA) needs to looked at.  The DUA can cache
>   X.500 entries in core, so there is no possibility of blocking
>   or even being slow.  The X.500 standard purposely does not
>   define how caching is done it is strictly a local implemenation
>   issue.  This allows caching to be managed in a number of ways.
>   For example, The cache could be managed to:
>         A. Penalize the first user of an LU by
>                  storing the returned X.500 entry in
>                  the cache.  When and why these entries
>            are deleted is a user decision.
>
>         B. The DUA periodically, say once a day or every
>            15 minutes, could update its cache for a specified
>            set of LUs.
>
>            C. The DUA does both A and B. It caches certain
>            LUs all the time and others for only a certain
>            amount of time after they were accessed.
>
>
>

R3.  The step forward from this is to leave the call as a set, but make
it a call issued after the simple CMINIT.... which was how we got to
Set_Partner_ID.  The call is local, sets a value, but does not block.  It
fits in cleanly with the other Sets because they do the same sorts of
things -- establish information that gets used at Allocate.  This
approach also has the advantage that programs that don't want any
additional function besides a DN in side information don't have to do
anything to get use of the directory.
>
> Having specific OSI set calls destroys the transparency of the
> API.  I must remind you that one of the overriding goals the CIW
> started with was to make CPIC run transparently over either LU 6.2
> or OSI TP.

R4.  The "beauty contest" sorts of discussion that went on were
about having two calls by the same name for similar, but
different, function.  There's a distinct argument against
muddling up CPIC with "new versions" of existing calls unless you
*really* have to, and the sentiment was that creating a new
CMINIT would be just one more thing for the programmer to keep
track of.  "So I use CMINIT here, because I'm an old program, but
here I use CMINIT2, because I'm new...."
> see first comment.
 ----------------------------------------------------------------------
  2. New function
     a. Specification of the type of identifier provided by the program

R5.  A new piece of function that you added in the CMINITA call proposal
was an identifier to point out what kind of name the program was passing,
e.g., was it an X.500 DN, a DCE DN, a local name, etc.  This seems
promising, and could easily be added to the existing Set_Partner_ID call,
but there are a couple of reasons why it probably shouldn't be added.

R6.  The first reason is that it's not needed.  I talked to the naming
experts I could get hold of and they confirmed my belief that you would
be able to tell what kind of name it was by looking at the name.  Thus,
for instance, DCE names look only like DCE names and are instantly
recognizable as such.  There are two forms of DCE names -- either one
that is fully X.500 compliant, or a "mixed form."  The mixed form is the
easiest to identify, because the latter portion of the name doesn't look
like X.500 at all.  If you're using a fully compliant X.500 name that's
for DCE, the latter portion will have equal signs and values, but a
special DCE-only name-type of "typeless" will be used.

R7.  Aside from that argument, this type of identifier is
limiting for the program.  The existing proposal allows the
program to specify an identifier -- it does not say *anything*
about what that identifier might be -- and promises that CPIC
will use it to try and find something in a distributed directory.
The type of directory used is determined by the implementation.
If the program initially runs on a CPIC implementation that
makes use of a roll-your-own directory, which is then later
updated to a DCE directory, and then later changed to make use of
a X.500 directory, the only thing that changes is the string,
which can be dynamically acquired.  If you force information on
the type of the underlying directory into the interface, you are
forcing more information that the program will have to specify
(and which will not be as accessible dynamically -- e.g., doing
a search based on PFID, determining the DN string, etc.).

> R6 & R7
>
> Why do names need to be identified?  In order for any
> type of directory mechanism to deal with
> a specific instance of a name correctly, it needs to know
> what type of name it is.  A couple of examples will make this
> clear.  If a relative distinguished name (RDN) is specified
> the DUA knows it may need to append some information on the
> front of it or depending on the directory it might search within
> its DSA arc.  If its a locally defined name the DUA may
> search other DSA attributes and not treat it as a DN or RDN.
> No mechanism can be expected to handle arbitrary names. The
> CMINITA proposal specifically is designed to be directory
> mechanism nuetral.  What mechanism is used is up to
> the CPIC user and his vendor.
>
> The naming experts you consulted are wrong, you can not
> positively deduce where a name came from by its format. For
> example:
>    1. /iso/us/boeing/G6160/hildebrand is a distinguished name;
>    2. so is Country = us, company = boeing, org = G6160,
>          surname = hildebrand
> Both are distinguished names but are written using different
> conventions.  What you indicate is true, there is a specific
> system which has specific conventions for writing names, but
> these conventions are far from universal.  We are familiar with
> several different conventions.  I suspect that the CMINITA
> name identifier will have to be expanded to include not only
> what the name is but what convention was used to write it so
> that it can be correctly parsed by the directory mechanism.
>
> The last point about unduly burdening the application program
> is not a problem.  There is no 'forcing' information about
> the underlying directory mechanism into the program - quite
> the opposite. What the program is telling the directory
> mechanism is what type of name it is dealing with so
> that it can deal with it the way the system administrators
> have determined is correct.
>
> The question about - what happens to the names a set of
> programs use when a roll your own directory becomes an
> X.500 based directory - it depends.  There is nothing
> special in a name, any directory only requires that it
> be drawn from a namespace which can guarentee that the
> name is unique and unambiguous.  The reason distinguished
> names were created was because it made it possible to
> administer a universal namespace that guareenteed unique
> names and could be easily administered.  If I had
> a local naming authority which drew names from the animal
> kingdom it would serve my purposes just fine.  When I
> converted to an X.500 directory the DUA would have to
> know these names were not ISO based names so that it
> could handle them in the way the system administrators
> decided was correct for this call of name. The DUA does
> the conversion not the program or programmer.
>

 ----------------------------------------------------------------------
2. New function
   b. Specification of association/session addressing in the directory
      entry (e.g., inclusion of NSAP)

R8.  You've included the NSAP information as part of the
information that would be retrieved from the directory.  As was
discussed at the sig meeting after the June CIW, this is the
equivalent of putting the network-layer information required to
establish an SNA session into the interface.  This type of
information is not currently part of CPIC, and the inclusion of
the NSAP is also not part of the AP OSI proposal.  If we want to
include this information we need to first update those other
portions of the architecture so as not to get into the "you do it
here this way, but you do it there that way" trap I've already
discussed.  Right now, the OSI proposal places such info outside
the bounds of CPIC and the existing AD directory proposal does
likewise.
>
>AT the API level a user requests a conversation with a partner via
>a partner-lu name.  The partner-lu name is a user friendly handle
>that still must be resolved into some type of network address.
>In the SNA work this is done by defining local LUs on all peer
>VTAM systems and sysgening into VTAM the addresses of its peer
>systems so that is can search for the LU.  To say that OSI differs
>completely from SNA is not true - both have to resolve addresses
> in order to make a connection, the only difference is how they
> do it.
>
>The concept that the 'interface' becomes involved in the lower
>level addressing problems is incorrect.  The CMINITA proposal
>says nothing about exposing addressing information to the
>interface user.  Any retrieved addressing information is given
>to lower level - vendor supplied - routines.  Thus if your CPIC
> program is sitting on an SNA stack it will simply take the
>partner-lu name and give it to VTAM, under OSI it would go
>to a side info mechanism which would return addressing information
>into internal buffers that service the OSI lower level components,
>such as ACSE to use in making an A-ASSOCIATE PDU.
>
>Thus the CMINTA proposal conforms to the existing OSI proposal
>in keeping the directory separate from CPIC.

R9.  Personally, I'm not crazy about the notion of including this
information in the CPIC interface.  It's something that the application
shouldn't have to worry about, and doesn't today, but I understand your
concern about where the information will come from for OSI.  Right now,
we presume that session/association addressing information is available
from a lower layer (i.e., either the SNA or OSI protocol stack) and that
doesn't seem to be true for OSI.  The correct place for this question to
be answered is the OSI SIG -- if the OSI SIG decides to include NSAP etc.
as a Set call (with all the incumbent implications) then we can proceed
to see about getting it in the directory.
>
> This has been answered above.  One exception, I would take is that
>how all this is done dramatically affects the API as a whole, so
>the OSI SIG is too narrow a group to be responsible for this.
>

R10.  One thought to keep in mind on this point is whether it's wise to
do this from a performance view -- APPN, for instance, keeps it's control
point name (the moral equivalent of an NSAP, I think) in a different
directory for some very good reasons and would never consider using
something as slow as the DCE directory.  DCE's distributed directory
makes no promises of real-time updates for changes.
>
>refer to the discussion of X.500 DUA's and caching.
>

R11.  Another thought, which may come from my SNA-centric view of the
problem (and hence may not be as applicable for OSI), is that today a
system might have hundreds of programs that are available via a single
LU/CRM.  The same situation seems to be true for OSI -- multiple programs
are accessed via a single application-entity.  In SNA, partner programs
get to their partners by providing the LU name, not the session
addressing information for establishing a session with the LU.  If we
*were* to put the session addressing information for the LU into the
directory at each of those programs, there would be a huge duplication of
information (if the LU had 100 programs on it, all 100 program objects
would have the same information).  It gets worse when you consider
changing the information.  By just having the program use the LU name,
the duplication is limited and any change of session information is
hidden from the application.  It seems like this concern is also
applicable to OSI (which would mean you would want to store the NSAP
stuff somewhere else, in an object for the application-entity similar to
the way info for LUs is stored elsewhere), but I'm not OSI-knowledgeable
enough to be sure.
>
>
> Moving stuff around the directory is a
> mechanical problem which we have found to be easy and fast.
> I will send more mail to directly the NSAP problem - the
> OIW directory objects solve the problem.
> The format of the OSI directory objects has been standardized
> by the OIW to specifically accommodate moving programs about
> the network.
 -----------------------------------------------------------------

You mentioned in your note that you'd like to see progress on the
directory work by the end of the summer, and I agree.  There hasn't been
much electronic traffic so far -- I assume a lot of people have been out
for summer vacations (it could never be that they find this stuff boring)
 -- but maybe we can get things moving again.  Rich sent out meeting
minutes after the last SIG with some questions that still need to be
resolved.  I'll try and get a response to those out this week or early
next week and maybe we can see how the SIG sees about the existing
directory proposal.  If we can reach agreement, I'd be happy to ask for
interim AP approval in August.  In September we could focus on what needs
to be done to get CP by the end of the year.
>
>I do not believe there is sufficient agreement on how directory
>stuff should work to have AP pages in September.  The directory
>is far too important to rush.
>

I should be in the office more regularly -- no large disjoint blocks --
through the rest of the summer, so hopefully my response next time will
be more prompt.  Sorry about the delay this time.  I look forward to your
reply.

Regards,
Mel